In a large Ethernet network, Address Resolution Protocol (ARP) traffic can get extremely high, inundating the network. ARP is used by nodes in a network to determine the Media Access Control (MAC) address of another node whose Internet Protocol (IP) address is known. For example, if a node needs to send a packet to a destination node, the MAC address of the destination node must be known and included in the Ethernet packet header for IP routing. If the MAC address is not known, the node floods the network with an ARP request, including the IP address that needs to be resolved to a corresponding MAC address. A node that receives the ARP request matches the IP address in the ARP request to its own IP address. If it matches, then the node forms an ARP reply packet including the IP-to-MAC address binding (i.e., both the IP address and the MAC address of the node corresponding to the IP address), and sends the ARP reply packet to the ARP request sender. Note that IP-to-MAC address bindings may change over time and also may become stale as is further described below.
ARP requests are also generated in situations where an IP-to-MAC address binding times out. Each node may cache IP-to-MAC address bindings that it has resolved in a local ARP table. A timestamp is maintained along with each binding. The timestamp denotes the last time at which the node received a packet that informed of the binding. To ensure that stale bindings are not used, any entry with a timestamp older than the “ARP-timeout” is considered unusable and is either deleted from the local ARP table or is marked as stale. Most LINUX kernels use a value of 30 seconds for this timeout. Some recent WINDOWS kernels use a timeout value that is randomly distributed, for example with a mean of 30 seconds, a minimum of 15 seconds, and a maximum of 45 seconds. If a packet needs to be sent to a destination IP address in a stale, or a non-existent entry, an ARP request is generated and broadcast over the entire network to re-resolve the IP-to-MAC address binding before sending.
As indicated by the situations described above, ARP traffic can potentially inundate a large Ethernet network, especially when there are situations where each node in the network needs to communicate with all other nodes or many other nodes in the network. This traffic can significantly reduce the amount of bandwidth available for applications in the network. As a result, the quality of service for applications, such as voice-over-IP, streaming video, or other large bandwidth or low latency applications, can be negatively impacted. Also, a large numbers of ARPs, i.e., ARP requests and replies, waste a significant amount of CPU time on nodes. Also, unnecessary ARPs can also increase flow-setup time, which especially may impact short flows, such as flows used for scientific applications.